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ABSTRACT 



In UMTS or EDGE or a similar network, each new call 
specifies a required QoS on handover (a Seamless Service 
Descriptor) and an acceptable level of degradation (Service 
Degradation Descriptor); a call Ls only accepted into a cell 
if the QoS requirements in the two descriptors can be met, 
and if the QoS requirement in the two descriptors of existing 
calls will not be unacceptably affected. 
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QUALn Y OF SERVICE CONTROL IN A MOBILE 
TELECOMMUNICATIONS NETWORK 



CROSS-REFBRENCE TO RELATED 
APPUCATION 

[0001] This application claims priority of European Patent 
Application No. 00303888.2, which was filed on May 9, 
2000, 

BACKGROUND OF THE INVENTION 
[0002] 1. Field of the Invention 

[0003] This invention relates to a method of improved 
quality of service control in a mobile telecommunications 
network, such as the Universal Mobile Telecommunications 
System (UMTS) or the Global Packet Radio Service (GPRS) 
Enhanced Data-rate GPRS Evolution (EDGE), and to appa- 
ratus for carrying out the method. 

[0004] 2. Description of the Prior Art 

[0005] Enhanced second generation and third generation 
of mobile systems will provide ditfcrenl services to end 
users, extending the scope of .second generation mobile 
systems from simple voice telephony to complex data appli- 
cations, for example voice over IP, video conferencing over 
IP, web browsing, email, file transfer, etc. llie use of circuit 
switched services for Real Time (RT) applications guaran- 
tees a high Quality of Service (QoS) but uses the system 
capacity in a consuming and wasteful manner This is due to 
the fact that a dedicated link is maintained throughout the 
entire lifetime of a connection. On the otlier hand, packet 
switched services provide a flexible alternative for RT data 
tralBc over a radio interface as set out by B. Jabbari, E. H. 
Dinan, W. Fuhrmann, in "Performance Analysis of a Mul- 
tiUnk Packet Access tor Next (ieneration Wireless Cellular 
Systems", PIMRC 1998, in the sense that they use the 
system capacity more efficiently, allow tor user idle lime, 
and adopt a volume charging policy. Moreover packet 
switching may Iw more appropriate in .scarce resource 
environments such as that found at the radio interface in 
mobile communications. ThLs is since additional system 
capacity may be realized over the air interface by taking 
advantage of the statistical multiplexing gain inherent in 
packet switched systems. However maintaining the QoS 
comparable to that of circuit switched system for RT ser- 
vices is an interesting challenge. 

[0006] This invention addresses the problems centered on 
Admission Control of packet data flows with Quality of 
Service (QoS) requirements. Traditional packet transmission 
systems operate as queuing systems, where each packet is 
transmitted at any time. This results in a u.ser perceived 
system behavior with a low Quality of Service, as the 
traasport network does not maintain certain delay bounds on 
the data. Novel scheduUng mechanisms overcome these 
limitations, by assigning guaranteed minimum bandwidth to 
individual flows. Provided that the offered data of one flow 
does not exceed this guaranteed rate within a given time 
interval, the user may assume no congestion related delay in 
such QoS scheduling systems. These assumptions only hold 
as long as the total offered load associated with QoS 
enriched flows is lower than the total output capacity of the 
shared link. Therefore it is necessary to have a .sy.stcm entity 
which controls the admission of new flows to the system. 



Iliis entity is called Connection Admis.sion Controller 
(CAC) and it decides on the admission of new flows. 
Traditional CAC Algorithms are not designed to handle 
flows in a highly dynamic environment as found in wireless 
transmi.s.sion systems. The present invention .specifically 
addresses these issues. 

[0007] Broadly speaking, it is possible to divide the types 
of service of third generation mobiles into two main classes: 
Real Time services (e.g., voice, video conferencing, etc.), 
and Non Real Time services (e.g., database applications, 
web browsing, email, etc.). The UMTS QoS Technical 
Report, rrU-R (source: Nokia), January 1999 defined four 
distinct traffic classes, for Universal Mobile Telecommuni- 
cation Systems (UMTS): 

[0008] Real Time cla.s.ses (Conversational and 
Streaming) 

[0009] Non Real Time classes (Interactive and Back- 
ground) 

[0010] Table 1 describes each one of these classes along 
with their characteristics: 

TABLE 1 



Conver- Preserves time Vbice over IP Low jitter 

sational relation between Video Low delay 

Convereational pattern 



Stream- Preserves time Real-time Low jitter 

ing relation between video 




[0011] The traffic classes have QoS attributes associated 
with them and these attributes include the following facets: 

[0012] The traffic characteristics specified in terms of 
bandwidth: 

[0013] The peak rale (bit/sec), 

[0014] The minimum acceptable rate (bit/sec), 

[0015] The average rate (bit/.sec), 

[0016] The maximum burst size (the maximum 
number of consecutive bits sent at the peak rate.) 

[0017] llie rehability requirements of the connec- 
tion. These include: 

[0018] The Bit Error Rate (BER) or Frame Error 
Rate [PER], 

[0019] The maximum loss ratio (the proportion of 
received packets to undelivered packets). 
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[0020] ITie delay requirements including: 

[0021] ITie maximum tolerated delay (ms), 

[0022] ITie maximum tolerated jitter (ms) (the 
variation in delay). 

[0023] This top-level of traffic class classification can 
support many QoS decisions without the need to examine 
closely the set of QoS attributes. For example conversational 
trafiSc could get no backward error correction assigned 
exclusively based on its traffic class characterization. 

[0024] Each traffic class is characterized by a set of QoS 
requirements that needs to be satisfied in an end-to-end 
mode. That is, both the wireless and the fixed .subsystems 
that make up a mobUe environment (see FIG. 1) need to 
implement structures responsible for providing and main- 
taining the required QoS. 

[0025] Many QoS requirements such as guaranteed band- 
width can be achieved for individual data flows by appro- 
priate scheduling strategies. These systems make one major 
assumption, which is: "The total ofifered traffic load to the 
scheduling system is lower than the output capacity." Thus 
the amount of accepted load in the system has to be 
controlled and is critical for the successfiil implementation 
of QoS scheduling. For wireless systems there are two 
special problems. Mobifity of users among different radio 
cells results in dynamic load patterns in individual cells, and 
changing radio propagation conditions result in varying 
capacity for individual links. Thus the amount of offered 
load (of already accepted calls) and the output capacity vary 
Besides these technical problems there is usually the eco- 
nomic desire to achieve high network utilization. A conser- 
vative CAC will possibly reject more load than what might 
have been acceptable. 

[0026] It is desired to provide a method and apparatus 
which permits more efficient use of bandwidth, improve- 
ment of end to end service quality, and improvement of load 
balancing in the network. 

SUMMARY OF THB INVEN llON 

[0027] In UMTS or EDGE or a similar network, each new 
call .specifies a required QoS on handover (a Seamless 
Service Descriptor) and an acceptable level of degradation 
(Service Degradation Descriptor); a caU is only accepted 
into a cell if the QoS requirements in the two descriptors can 
be met, and if the QoS requirement in the two descriptors of 
existing calls will not be unacceptably affected. 

BRIEF DESCRlFnON OF THE DRj'WlNG 

[0028] ITie features, aspects and advantages of the present 
invention wiU become better understood with regard to the 
following description, appended claims and accompanying 
drawings where: 

[0029] FIG. 1 iUustrates schematically a UMTS network; 

[0030] FIG. 2 illustrates Quality of Service architecture in 
the UMTS system; 

[0031] FIG. 3 illustrates a Seamless Service Descriptor 
and Service Degradation Descriptor values; 

[0032] FIG. 4 illustrates a sample loss profile; 



[0033] FIG. 5 illustrates Quality of Service management 
.structure components in the arrangement of the invention; 
[0034] FIG. 6 illustrates a sample connection status table; 
[0035] FIG. 7 illustrates the general strucmre of a con- 
nection admission controller 

[0036] FIG. 8 illustrates the deci.sions made in a connec- 
tion admission controller according to the invention; 
[0037] FIG. 9 illustrates the interaction of a scheduler 
with standard Quality of Service management components, 
in addition to the inventive arrangement; and 
[0038] FIG. 10 illustrates the time intervals between 
RLCs and packets of the same connection. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

[0039] In FIG. 1, a mobile telecommunications network 
10, specifically the UMTS, comprises a Mobile Terminal 
(MT) 12 which communicates over an air interface 13 with 
a Base Station (BS) 14 which has a fixed connection 16 to 
a fixed network subsystem 18, which may be either an IP 
(Internet Protocol) network or the PSTN (Public Switched 
Telephone Network). 

[0040] The QoS (Quality of Service) architecture can be 
represented as in FIG. 2, as a functional decomposition; 
QoS can be treated as a series of "chained services" oper- 
ating at different levels; such an approach is suggested in 
Technical Specification Group Services and System Aspects, 
QoS Concept version 1.1.0, 3GPP, 1999. 

[0041] In UMTS, Teraiinal Equipment (TE) 20 can be 
connected to an MT 12; the BS 14 forms part of a UTRAN 
(Universal Terrestrial Radio Access Network) 22 which is 
connected through an Edge node 24 and Core Network (CN) 
Gateway 26 to a further TE 28. 

[0042] The end to end QoS service 30 can be regarded as 
made up, at a first level, of a Local Bearer Service 32, 
between the TE 20 and MT 12; UMTS Bearer Services 34 
between MT 12 and CN Gateway 26; and External Bearer 
Service 36 between CN Gateway 26 and TE 28. 
[0043] At a second level, the UMTS Bearer Services 34 
are made up of Radio Bearer Services 40 between the MT 
12 and the Edge Node 24, and a CN Bearer .Service 42 
between the Edge Node 24 and the CN Gateway 26. At a 
third level the Radio Bearer Service 40 is made up of a Radio 
Service Bearer 50 between MT 12 and UTRAN 22, and lu 
Bearer Services 52 between UTRAN 22 and Edge Node 24. 
At this level, the CN Bearer Service 42 is a Backbone Bearer 
Service 54. 

[0044] At a fourth level there is a UTRA (U . . . T . . . 
R . . . A . . .) FDD/TDD (F . . . D . . . T . . ./P . . . D . . . 
D . . .) Service 60 between MT 12 and UTRAN 22, and a 
Physical Bearer Service QoS 62 between the UTRAN 22 
and Edge Node 24. 

[0045] In this specification, most of the QoS terms used 
are based on Tratlic Management Specification, Version 4.0, 
The ATM Forum, Technical Committee, af-tm-0056.000, 
April 1996; in addition the term "loss profile", a wireless- 
specific QoS parameter, is described by S Singh, "Quality of 
Service Guarantees in Mobile Computing, Computer Com- 
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municatioas". Vol 19, pp 359-371, 1996. However, in con- 
trast to QoS for ATM (AsyiKhronous Transfer Mode) sys- 
tems, in the arrangemeat according to the iQventioB, QoS 
maintenance is not only adaptive, but it is maintained 
throughout the hfetime of a connection. 
[0046] In the description of a specific embodiment of the 
invention which follows, the assumptions made are that: 
[0047] 1. All QoS transmissions have to be embedded into 
a data flow. A data flow is a sequence of data packets from 
the same source to the same destitiation in the network, for 
which the user has certain QoS requirements. Each radio 
bearer is related to a single data flow. Because multiple radio 
bearers might be established for a single user, multiple data 
flows could exist simultaneously that are related to a single 
user, too. In the following all data flows are handled sepa- 

[0048] 2, Each Connection Request (CR) contains QoS 
requirements. The QoS requirements contain three parts. 
The first part (A) is a top-level classification. If not explicitly 
given this classification can be derived from actual values 
from B, e.g. from the delay requirements. The quantification 
of such conversion table is out of scope for this proposal. 
Part B contains basic traffic specifications in means of 
bandwidth, delay and reliability. The third part (C) is wire- 
less specific and deals with the question of how to deal with 
the flow in ca.sc of network congestion situations, mostly due 
to link degradation. It is assumed that each CR is specified 
with the parameters for B and C. If these are not explicitly 
notified in a CR, it is assumed that it Ls possible to assign 
appropriate values to the unspecified fields. 
[0049] 3. The variable link is a.ssumed to be part in a 
multi-hop packet routing architecture and to be the only 
bottleneck, where potentially congestion situations may 
occur. This is ju-stiflcd by the as.sumption thai a fixed link 
backbone network with the same bandwidth capacity com- 
pared to a wireless network is relatively cheaper to build. 
Therefore in our expected application field the network 
operator will make sure during the network planning that 
enough (cheap) backbone capacity is available to support the 
relatively expensive wireless network. 
[0050] 4. Because a rate conserving scheduling strategy is 
used in the scheduler, the scheduler guarantees the required 
data rales, as long as the scheduling system is not congested. 
This is the case as long as the total offered load is lower than 
or equal to the available effective throughput within a given 
monitoring interval. 

[0051] According to the present invention, two novel 
service descriptors are required, both of which permit the 
description by a user of a requested service in terms suited 
to the characteristics of a wireless interface. 
[0052] The first descriptor is a Seamless Service Descrip- 
tor (SDD) by which a user specifies the level of service 
which the user requires during a handover from one tele- 
communications cell to another. For simplicity this may be 
exemplified by integer gramJarity on a scale of 1 to 5; an 
SSD value of 5 means the highest quality of seamless 
service, such as that required for video handover; for video 
a service of quality 4 may be tolerable but an SSD value of 
3 or less would render a video service unwatchable. 
[0053] For a voice service, an SSD value of 3 will prob- 
ably be acceptable, becau.se the human brain is capable of 
interpolation to smooth out errors of transmission. 



[0054] For a service such as file transfer, when teal time 
transfer is not cs.scntial, an SSD of 1 would be acceptable. 
[0055] FIG. 4 illu.stratcs the three examples just given. 
[0056] Naturally, a u.ser will be required to pay more for 
the higher SSD levels. 

[0057] A second descriptor, a Service Degradation 
Descriptor (SDD) allows a user requesting a new link also 
to specify the level of service degradation, and the type of 
degradation, which a user is prepared to permit. On the 
integer scale of 1 to 5 the de-scriplor defines the level by 
which the user will tolerate degradation; for example, the 
voice user may not be prepared to tolerate any loss, so 
SDD--;, .see FfO. 4. 

[0058] The SDD is based on a loss profile, such as that set 
out by S Singh, "QuaUty of Service Guarantees in Mobile 
Computing, Computer Communications", Vol 19, pp 359- 
371, 1996. 

[0059] Suppose there is resource deterioration, e.g. a 
decrease in the quality of the air interface so that radio Unk 
capacity is reduced. The question may be asked, should 
payload be preserved at the expense of jitter requirements? 
[0060] FIG. 4 shows a typical loss profile for a connection 
and specifies that, as a first step, jitter may be increased from 
ten milliseconds to twenty milliseconds, then as a second 
step in degradation, BER (Bit Error Rate) may be increased 
from 10-* to 10-^. 

[0061] Thus SDD specifies how, when a resource insuffi- 
ciency occurs, the QoS requirements of that particular call 
may be degraded. 

[0062] A fourth element which is specified is the Policer 
Flag by which the user indicates how the system may react 
if that user exceeds his allocated bandwidth; the concept of 
a Policer Flag is known in ATM systems. 
[0063] The four elements Seamless Service Descriptor, 
Service Degradation Descriptor, Loss Profile and Policer 
Flag are all specified in a Connection Request (CR) which 
is issued for each application which is requesting a wireless 
link, in both the uplink and the downlink, and regardless of 
the transport scheme used, which may be I'CP ( Transport 
Control Protocol), UDP (User Data Protocol) etc. 
[0064] On the ba-sis of the Connection Request, the net- 
work makes a decision whether to accept or reject the 
request, depending on whether sufficient capacity is avail- 
able to provide the .service, and on whether supplying the 
requested service wiU afl:ect current connections to an unac- 
ceptable degree, i.e. to go beyond the SSD and/or SDD 
descriptors of these current connections. 
[0065] Also, when a service to be handed over is not 
robust, such as a video service, a request may be made for 
bandwidth within the target cell; the SSD functionality 
allows an incoming, high value SSD service to "borrow" 
bandwidth from a lower value SSD service akeady within 
the cell, so that quality can be maintained on handover. 
[0066] The decision is made by a QoS management struc- 
ture, the components of which are shown in FIG. 5. The 
components are viewed as logical entities, that is, the 
location is not indicated. The structure may be located in the 
MT 12, in a BS 14, or in both. 
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[0067] ITie Connection Request CRi is supplied to a 
Connection Admission Controller (CAC) 70 which accepts 
or rejecus the request, as set out above. For an accepted 
request, the CAC 70 generates a "create flow queue" mes- 
sage 72, and a queue 74 of variable size is set up in the 
network layer for each CRi. Each queue comprises a vari- 
able size leaky bucket VBi with variable flow rate W. 
[0068] The output Oi of the bucket is monitored by the 
policer 76. Subsequently, as Ulustrated at 74', the RLC 
(Radio Link Control) protocol is initialized, as indicated at 
78, and RLC blocks are passed to a scheduler 80 which also 
receives input from a Radio Resource Manager (RRM) 82. 
llie scheduler 80 serves each flow queue depending on its 
QovS requirements, setting up Transport Frames (TF) 84. 

[0069] Referring again to the queue 74, flows with BEC 
(B ... E ... C ...) find that their ARQ (Automatic Repeat 
Requests) is set up and this is used for rctransmi.ssion of lost 
or erroneous blocks. (The ARQ process for real time traffic 
classes wiU, in general, be void). 

[0070] The components comprising the QoS management 
structure are the CAC 70, the policer 76 and the scheduler 
80. 

[0071] Considering now the CAC 70, the basic principle 
of a CAC is to collect a certain number of Connection 
Requests (CRi) from flow i, i-1 . . . n, where n constitutes 
the total number of already accepted and living flows. A flow 
is alive until the network or the user has terminated an 
established flow. 

[0072] A CR contams a set of QoS requirements, which 
builds the basis for the CAC algorithm to decide how much 
system resources this flow will potentially require. The CAC 
decision upon acceptance is thus driven by the question, if 
system resources will be sufficient to satisfy all existing plus 
the newly considered flow. Conservative CAC algorithms 
will do so if the probabUity of this decLsion Ls 100% proof. 
To increase link utilization many approaches aim for a CAC 
behavior which achieves probabilistic guarantees, .such as 
guarantees which hold for 55 minutes during an operating 
hour. These schemes are also referred to as over-reservation 
schemes. Given that the inventive usage of the parameter 
l^ss Profile and the novel parameter SDD are probabilistic 
metrics, it is assumed that over-reservation is used and/or 
temporarily accepted during operation. 
[0073] From a service provider point of view, the main 
goal of the CAC module is to admit a maximum number of 
CRs, and, at the same time, maintain the QoS requirements 
of existing connections. That is, the CAC module should 
avoid congestion in advance. In addition to this, independent 
from its actual implementation, the final output of the CAC 
module must be a Boolean value indicating whether the CR 
should be admitted or not. 

[0074] ITie CAC module receives a Connection Request 
(CR) from an application, network measures (multipath, 
path loss, and interference) from the Radio Resource Man- 
ager (RRM), and the trafSc characteristics along with the 
QoS requirements of all existing connections from the 
serving Base Station. It then decides, based on the previous 
information, whether the CR can be accepted or not. The CR 
can be originated either from a new call or from a handofl'. 
The CAC module should prioritize handoff CRs over new 



call CRs because, in general, interrupting a service in an 
active connection is more annoying to users than rejecting a 
new call. 

[0075] Besides loca 1 capacity estimates, CAC for wireless 
traditionally focu.scs on resource reservation for hand-off 
calls, which can lead to both extensive signaling overhead 
between ba.se stations and low link utilization due to pessi- 
mistic admission strategies. The Connection Admission 
Controller of the invention is not based on inter-cell resource 
reservation to guarantee a seamless service. Rather it uses 
the two new QoS parameters that are introduced (the SDD 
and the SSD) to either accept or reject an incoming request. 
In this model, each BS needs to maintain a table (a Con- 
nection Status Table) containing the connection identifier, 
SDD, SSD, and flie total virtual bandwidth used by each 
connections within the current ceU. FIG. 6 shows an 
example of a Connection Status Table. 
[0076] The general structare of the CAC 70 is shown in 
FIG. 7. It has two main parts, a Connection Impact Evalu- 
ator (CIE) 86 and a Boolean Decision Maker (BDM) 88. 
[0077] The CIE; takes as input the following parameters: 
[0078] The actual Connection Request, 
[0079] The available system rcsfmrccs (bandwidth 
and memory), of both the current cell and the neigh- 
boring cells, form the RRM, 
[(M)80] llie f\innection Status Tables, of both the 
current cell and the neighboring cells. 
[0081] Obviously, a protocol for exchanging information 
on existing connections between neighbor BSs at regular 
intervals needs to be specified. 

[0082] The CIE then outputs a set of probabilistic values 
predicting the impact of admitting the requesting connection 
on all existing active connections in the current and neigh- 
boring cells. Those probabilities are divided into two cat- 
egories: 

[0083] The probability values of blocking n other 
active connections PB(n) in the current and neigh- 
boring ceUs. For example, a Pb(1)-0.3 means that 
there is a probability of 0.3 of blocking one active 

[0084] The probability of degrading the QoS of n 
other active connections in neighboring cells; 

[0085] Probability of exceeding the delay require- 
ment P,(n) 

[0086] Probability of exceeding the jitter requirement 
Pi(n) 

[0087] Probability of exceeding the BER requirement 
Pb(n) 

[0088] Probability of exceeding the loss requirement 
Pi(n) 

[04^9] The BDM is the module that decides whether or 
not the CR is to be accepted. It is regulated by the prob- 
abilities issued from the CIE and a set of a)ngeslion metrics 
(the number of connection blocking Nj, the number of QoS 
degradation due to congestion N^, and the length of queues 
and buffers at the edge of the network N^.) One of the goals 
that the BDM needs to achieve is that its blocking and 
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service degradation probabilities should be less than the 
natural blocking and degradation probabilities if no CAC is 
implemented. 

[0090] FIG. 8 shows in detail the decisions made by the 
CAC 70. 

[0091] 'Itie input from the RM 82 and the other connec- 
tions into the CIE 86 can be regarded as taking into account 
the Radio Bearer Services 40 and 50 in FIG. 2, and the Link 
Congestion metric inputs can be regarded as taking into 
account the lu Bearer Services 52, the Backbone Bearer 
Service 54 and the ON Bearer Service 42 in FIG. 2. Thus the 
whole breadth of the UMTS Bearer Service M is covered 
and in effect the end-to-end service 30 can be improved. 
[0092] On receipt of a call request CR, and with input 
from the RRM 82, in step 100 the decision is "are system 
resources available?". If yes, connect; if no, the SDD is 
checked in step 102; in step 104 the decision is made 
whether accepting the new CR would degrade other con- 
nections; if yes, ie if the existing connections are prepared 
to accept degradation to allow the new call, then connect. If 
no, in step 106 the loss profile of the CR is checked. In step 
108, if this CR can be served according to its loss profile, 
connect; if not, the SSD is checked in step 110. In step 112, 
if it would block other connections to accept this CR, but the 
other connections can be stopped and restarted without iU 
effect, ie if we can "steal" bandvsfidth, then the CR is 
accepted; if not, the CR is rejected and the application is 
informed that the network is unable to accept the request. 
[0093] On acceptance, a new flow queue is created and a 
connection identifier is assigned to all packets which are 
issued for that connection. 

[0094] As an example, a CR can be rejected, even if 
system resotvces are available, if the CIE 86 outputs a high 
blocking probability value, and the congestion metrics indi- 
cate an increasing number of blocked connections. 
[0095] Although a specific CAC entity has been described, 
a distributed version would beneficially spread the required 
computational power to several units, and lower the 
response time to a request. 

[0096] Consider now the policer 76 in FIG. 5. In a 
network where diflerent connections are competing for 
resources, a policing mechanism is suited to monitor traffic 
sources, if they behave in compliance with their own .speci- 
fications. Furthermore a policer can interact and alter the 
offered load in order to make it flow compliant. In the 
pre.sent approach both actions are foreseen, while it is left to 
the user to select the operation mode. 
[0097] In this apphcation, a simple policer operating at the 
data hnk layer of the BS is described. Obviously its location 
can also be shifted e.g. to the gateway entry of the core 
network. The policer monitors and enforces lbs traffic char- 
acteristics (peak rate, average rate, and burstiness) of a given 
flow queue based on a token-based leaky bucket algorithm. 
[0098] The peak rate of a flow is controlled by simply 
comparing the bit inter-arrival time with the inverse of the 
peak rate specified when the Connection Request was 
issued. The bit inter-arrival time must be less than the 
inverse of the peak rate for a conforming traffic. The average 
rate is enforced by setting the leaky bucket's token arrival 
rate to the agreed upon average rate. Note that "bit inter- 



arrival time" underUnes that this is a volume dependent view 
and not done on a per packet ba.sis. 

[0099] It can easily be shown that the burstine.ss can be 
controUed by adjusting the size of the leaky bucket. Bursti- 
ness is the maximum number of consecutive bits sent al the 
peak rate. ITie size of the token-based leaky bucket can be 
set in order to enforce the agreed burstiness: 
[0100] For a given traffic, the size of the leaky bucket 
should be set lo: 



[0101] provided that the Average Rate is strictly smaller 
than the Peak Rate. If the average rate is equal to the peak 
rate, then the burstiness is not defined. This makes sense 
since the definition of the buistiness is the maximum number 
of consecutive bits that can be sent at the Peak rate. 
[0102] Concerning the action to be taken by the policer 
with regard to connections not conforming to the agreed 
upon traffic characteristics, the policer examines the "Policer 
Flag" specified within the connection request. If the Policer 
Flag is ON, this means that the user is willing to pay extra 
charges (according to a billing policy defined by the service 
provider) for the transmission of non-conforming packets 
(provided enough system resources are available). If, how- 
ever, the Policer Hag OFF, then the poHcer discards all 

[0103] On connection of a call, the network guarantees the 
user requirements as lo delay, jitter and a bandwidth. The 
case with which these requirements can be met depends on 
external conditions, primarily the air interface. The network 
may need to var>' the proportion of data and protection if the 
interface deteriorates, i.e. it may need to vary the bandwidth. 
Similarly, deterioration of the air interface may cause a 
concertina effect, ie the proportion of raw data within a 
packet is decreased. 

[0104] It is the scheduler 80 (see FIG. 5) which takes 

these factors into account. 

[0105] Considering first the arrangements in the prior art, 
for the apphcation to UMTS a scheduler is responsible for 
the order of traasmission of different RLC blocks within a 
transport frame. It is configured from Radio Resource Man- 
ager (RRM), located at the BS, with a set of Transport 
Format Combinations (TT'C) which have been a.ssigned 
during resource allocation to the flow. Each Transport For- 
mat (TF) is characterized by at least a coding scheme and its 
corresponding number of bits that can be transmitted. The 
scheduler chooses one TF that would optimize the hnk 
utilization and, at the same time, satisfy the QoS require- 
ments of all flow queues belonging to different traffic 

[0106] Different scheduling schemes may apply, depend- 
ing on the traffic direction. For wireless systems, as e.g. 
UMTS, there is one scheduHng method on the dedicated 
shared Adchannel, where the MS transmits in the upUnk 
direction over the air interface whenever it has data to send. 
In GPRS the MS has to perform an access procedure and its 
UL data is actively scheduled and signalled to the MS from 
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the central BS. In the downlink for all known system the BS 
synchronises all RI.C blocks and sends data at regular 
intervals. 

[0107] In the present invention, the scheduler is applied in 
a rate conserving manner to implement the QoS bandwidth 
requirements, that is, the scheduler monitors and grants 
access to the shared link to the individual data flows in 
proportion to their specified bandwidth requirements. The 
actual scheduling scheme is not relevant. 
[0108] FIG. 9 illustrates the interaction with standard QoS 
management components. The inventive arrangement with a 
variable queue 81, a CR 83 and an ARQ 85 interacts with the 
scheduler 80. The scheduler 80 also interacts with standard 
queues j and k each having a Connection Request CRj, CRk. 
Hie output of the scheduler is a stream of RLC blocks 84, 
which may be PDUs or ARQs. 

[0109] For the scheduler to meet all existing flow queues 
(the performance requirements of the scheduler), the QoS 

[0110] RT Traffic (l:i.sses: characterized by the fol- 
lowing QoS requirements (relevant to the scheduler): 

[0111] The maximum tolerable delay: Dmax, which 
is the maximum tolerable time it take.s for a Network 
Ijiyer Packet to be transmitted, 

[0112] The maximum tolerable jitter: Jmax, which is 
the maximum tolerable variation in packet delay, and 

[0113] The Packet Loss Ratio. 

[0114] Assumption 3 above focuses on delay issues for the 
parlituiar .scheduling system. It is assumed that there is no 
significant additional delay caused by the backbone net- 
work. ( )f course this inlluence may be estimated or signaled 
by some future QoS mechanism. If the influence of the 
backbone is available it will be subtracted from the flow 
requirements first and the new constraints will become 
tighter for our scheduler. 

[0115] In FIG. 10, let tj^,,, be the time interval between 
two consecutive RLC transmissions 84 bekinging to the 
same packet, and let Tj^^ be the time interval between the 
last RLC of packet i and the first RLC of packet i+1 for the 
same connection. 

[0116] Also let D; be the packet delay for a given packet 
i. So, Di-Tf„„+j.ti„,„. That is, in order to meet the delay 
requirement for a RT flow, the scheduler 80 must maintain 
the following inequality true: Ti,,^^,+^t^i^,^Dmax. 
[0117] In addition to this, the scheduler 80 must also meet 
the jitter requirement for a RT flow. That is, Di.,i-DiSJmax. 
Note that Di.^i-Di can be negative, assuming that a given 
packet can be buflered at the destination to maintain a smaU 
delay variation. Consequently, the scheduler needs to adjust 
the values of t^,;,, in order to meet both delay and jitter 
requirements. 

[0118] The loss ratio specified in the How queue specifies 
the fraction of packets that can be delayed over the maxi- 
mum tolerable delay (considered lost.) 

[0119] NRT Traffic Classes. Characterized by the 
following QoS requirements (relevant to the .sched- 
uler); 



[0120] Maximum tolerable delay: Dmax (class #3 
only), and 

[0121] Bit Error Rate: BER (classes #3 and #4) 

[0122] By adopting the previous terminology, the sched- 
uler needs to maintain the following inequality true for 
traffic class #3 flows: ri„,j,,+j;ti„,„§Dmax. 
[0123] In order to meet the BER requirement, the sched- 
uler needs to choose a TF having a coding .scheme that 
maintains the required BER. Note that lost packets for NRT 
clas.ses are retransmitted using an ARQ process, making the 
PHY-link BER requirements an optimisation process, not 
covered here. 

[0124] ITie scheduler 80 may find itself in congestion 
situations due to several reasons. The system may be over- 
loaded by aggressive CAC strategies or unexpected Hand- 
otls into the cell under consideration. Also the estimated 
traasmis,sion capacity might be overestimated. This can 
happen when links degrade in quality and mote systems 
resources are required to achieve the former effective 
throughput. 

[0125] Several stages of load balancing in ca.se of a 
congestion simation are proposed: Firstly marked packets by 
the policer from flows with non-flow compliant behaviour 
are discarded. Then if the .sy.stem resources are still limited, 
the scheduler initiates a RRM procedure to alter some flow 
requirements. T\ic exact procedure is out of scope here. 
BasicaUy it will base its decision on the loss profile of 
individual flows and find a flow that is suited to be degraded. 
This degraded parameters wiU then be notified back to the 
scheduler. This Ls repeated until the scheduler find itself in 
not congested anymore. When the situation is stable the 
former degraded flows are restored in a reverse manner. If 
possible this mechanism also informs (via a control plane) 
the corresponding application of the changes in QoS tenms. 
[0126] In the invention the inherent characteristics of the 
air interface of a mobile wireless packet .switched transmis- 
sion system are taken into account when aiasidering the 
QoS for traffic flows across the air interface. This is since the 
SSD, SDD and LP together realisticaUy reflect the achiev- 
able QckS for a wireless service. There are specificaUy two 
occasions where the achievable QoS temporarily alters. 
During normal operation with no handover scenarios the 
available capacity may change substantially due to altered 
radio conditions for individual links. This reduced link 
capacity may yield scheduling congestion situations. For 
handover liandofl' .scenarios there might be additional load, 
which cannot be easily rejected by Admission Control 
mechanisms, as it is generally not desired to cut of existing 
flows. These additional load may also cause congestion 
siniations. In the case of Handofli this amounts to an 
improvement on existing .solutions because existing .solu- 
tions reserve bandwidth in neighboring cells in order that 
handovers liandoft' are smooth for R T services. ITiis method 
while robust reduces the capacity of the system moreover in 
Third Generation (3G) systems there is the added compli- 
cation of having ongoing variable bandwidth demands at the 
time of handover. Under this circumstance the overhead of 
reserving bandwidth to guarantee the QoS at handover 
becomes costly in terms of cell capacity. Therefore having a 
method which takes into account the demands of new 
connections in a highly flexftile manner would be highly 
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desirable since cell capacity would be used in a more 
effective manner- Moreover the invention can be applied in 
a general sense to packet switched services since (he polic- 
ing and scheduling elements take care of the tralEc behavior 
cither side of a handover/hand -off. Finally the invention 
allows for more aggressive over-reservation of system 
resources hence a higher network utilization, because it is 
possible to overcome potential congestion situations in such 
manner, that the affected services are degraded in such way 
that this is still acceptable for the users. 
[0127] While the invention has been described with ref- 
erence to the UMTS, it is applicable to any enhanced second 
generation or third generation mobile telecommunications 
system. 

[0128] While an embodiment of the invention has been 
described, it should be apparent that variations and alterna- 
tive embodiments could be implemented in accordance with 
the invention. It is understood, therefore, that the invention 
is not to be in any way limited except in accordance with the 
spirit of the appended claims and their equivalents. 
What is claimed is: 

1. A method of call acceptance in a telecommunications 
cell comprising the step of providing for each requesting call 
a quality of service descriptor specific to that call, and 
accepting that call only when the required quality of service 
can be provided and also the required qualities of service of 
existing calls will not be unacccptably affected. 

2. The method according to claim 1 in which the quality 
of service descriptor comprises a service degradation 
descriptor which specifies a preferred type of degradation of 
quality of service. 



3. llie method according to claim 2 in which the service 
degradation descriptor specifies acceptable decreases in jit- 
ter and bit error rate, and the order in which such decreases 
are to be applied. 

4. The mcthtxl according to claim 3 in which there is also 
provided a second quality of service descriptor specific to 
each requesting call comprising a seamless service descrip- 
tor which specifies a preferred quality of service during a 
handover from one telecommunications cell lo another. 

5. The method according to claim 4 in which the seamless 
service descriptor specifies quality of service on handover 
by specifying bandwidth requirements. 

6. A wireless mobile telecommunications network com- 
prising a cote network, a plurality of base stations and a 
plurality of mobile terminals, there being a connection 
admission controller, a policer unit and a scheduler, com- 
prising means to specify at least one quality of service 
descriptor specific to a requesting call, and in that the 
connection admission controller is arranged to accept the 
requesting call only when the quaUty of service in the 
descriptor can be provided, and the qualities of service 
descriptors specific to existing calls will not be unacceptably 
affected. 

7. A network according to claim 6 in which the connection 
admission controller comprises a Boolean decision maker 
and a connection impact evaluator arranged to assess the 
impact of accepting a requesting call into an active telecom- 
munications cell. 



